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ABSTRACT 



Currently the Indonesian Navy Computer Center 
(Dispull ahtal) has a need for a Personnel Data Base System 
which satisfies all of the required applications. By ana- 
lyzing the aspects of the personnel management in the Navy 
and the functions required to implement the management poli- 
cies, the author has determined the data elements* relation- 
ships. Further, from the data elements* relationships and 
using logical Data Base model design methods, the author has 
derived a Personnel Data Base model. Topics discussed 
include: transformations of data elements between their 
logical views and physical representation, security, Data 
Base dictionary structure and characteristics, journalizing 
transactions to facilitate Data 3ase recovery, and Data Base 
administration. The author's efforts indicate that the 
Personnel Data 3ase presented herein is worthwile and should 
be implemented. This involves the organization and formation 
of a Data Base Administration, and continuation and comple- 



tion of the design. 
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I. I NTRODO CTION 



Since 1977 Dispullahtal (Indonesian Navy Computer Center) 
has worked at developing a Personnel Data System (PDS) with 
emphasis on collecting data, and then processing and pre- 
senting information 1 to users (especially the top manage- 
ment) as it is needed to facilitate decision-making. 

The data which has been collected by Dispullahtal using 
PDS for each person employed by the Department of Navy, both 
military and civilian, comes primarily from Janminpersal 
(Department of the Navy Personnel Administration) as well as 
other departments involved with personnel administration and 
treatment. After its collection, the data is stored in files 
which are related to the various applications in the PDS. 
Currently the PDS only includes the functions of data sto- 
rage and information retrieval. Since 1977 Dispullahtal has 
succeeded in convincing the system’s users that their needs 
can he served and that new is the time to expand the PDS. 
The period for this expansion has been designated as "Data 
Mechanization." The users have come to realize that they 
depend on Dispullahtal for the processing of data and 
reporting of information which is timely and accurate. Prior 
to 1979, the system was not able to provide these services 
in the manner required because of the lack of up-to-date 



within the context of this thesi?. Data and Information 
are meant to have two distinct meanings. Data raters to 
facts collected from observations or measurements, or refers 
to the values physically recorded in the file or Data Base. 
Information refers to the meaning assigned to those fact and 
values as a result of interpretation, correlation, etc. of 
data. Data is processed into information so that it can be 
understood ar.d employed by users. [Ref. 3] 
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information in the system's files. Seeing this problem, the 
Navy conducted a census of its personnel in 1979 and this 
data is currently being integrated into the system. 

According to the current user requirements, Dispullahtal 
should be able to respond immediately, and at any time, with 
information such as historical data (e.g historical rank, 
education, profession etc.) on any individual. For these 
requirements Dispullahtal has started organizing all the 
data into a Data Base System. This leads to the next phase 
of Dispu llahtal ' s planning which is "Automation." 

Data 3ase Systems are needed for accomplishing the 
requirements and demands because information is only of 
value so long as it supports the decision-making process and 
results in better decisions. To be useful for decision- 
making, information must be current. For the information to 
be current, the data on which it is based must also be cur- 
rent. Current, accurate information is essential for the 
effective operation of an organization. Therefore, if is 
necessary to have a means of collecting, organizing, stor- 
ing, and correlating the data and to be able to extract and 
distribute the information as it is needed. 

C. J. Date [Ref. 3] defines a Data Base system as 

a comcuter- based recordkeeo ina system; that is, a 
system whose overall purbose is to record and 
maintain information. The information concerned 
can be anything that is deemed to be of signifi- 
cance tc the organization the system is servina- 
anything, in other words, that may be necessary £o 
the decision-making processes involved in the man- 
agement of that organization. ... 

Data Base system involves four major components: 
data, hardware, software and users. 

Date further defines a Data 3 ase as 

a collection of stored operational-data 2 u$ed by 
the acplication systems of some particular 
ent er prise . 3 



2 operational-data would probably include: oroduct data, 

account data, patient data, student data, planning data. 
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A Data Bass system provides the enterprise with central- 
ized control of its operational data. Some of the advantages 
that accrue from this centralized control are: 

- Redundancy can be reduced, 

- Inconsistency can be avoided, 

- Data can be shared, 

- Standards can be enforced, 

- Security restrictions can be applied, 

- Integrity can be maintained , and 

- Conflicting requirements can be balanced. 

Based on these above mentioned advantages, personal 
experience in processing personnel data prior to coming to 
the Naval Postgraduate School, and information gained from 
courses taken recently at this school, this author is 
attempting to design "The Elementary Personnel Data Base 
System for the Indonesian Navy". This Data Base System is 
proposed in order to fulfill some of the requirements of the 
.lanacement Information System (.113) in the Navy as posted in 
the "System Informasi Pembinaan TNI-AL" (Navy MIS). 

Tc accomplish this goal, the author obtained information 
concerning user requirements from Dispull ahtal. The three 
sections of this thesis are: 

1. User requirements definitions which analyze the user 
requirements and data elements. 



Enterprise is simolv a convenient, qeneric term fop anv 
reasonably self-contained commercial, scientific, technical^ 
or ether type of organization. Some examples are: 
Manufacturing' Company, 3ank, Hospital, University, 
Government Department. 
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2. Data Base design which considers the data model and 
special discussions for further implementation. 



3. Conclusions and recommendations. 



At the end are appendices which contain the List of data 
elements from file system. Data Base Dictionary, and Data 
Base personnel tables. 



Melvin 3. Klein and Melvin W . Lifson [Ref. 9] in their 

lecture notes regarding Systems Engineering says that 

A svstem, to be useful. must satisfy a need. 
However, designing a system no just meet the cur- 
rent need is not usuallv sufficient. With few 
exceDticns, the svstem must be able to meet a con- 
tinuing ana changing need over a specified period 
of time in order to justify the investment in 
time, money, and effort. 

It is the author's believed that the proposed system will 
be able to be easily improved according to the technologica 1 
demands of the future. 
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II. OSER I RESENTS DEFINITIONS AND ANALYSI S 

A. GENERAL 

Wise personnel decisions demand data about the individu- 
als upon which decisions may be based, the special require- 
ments of jobs, and interactions between these two. 
Systematic procedures exist for gathering this data about 
people, jobs, job behavior; and for estimating their inter- 
relationships. This should lead to the assurance that 

the right oeople move into the right jobs at the 
right times and under the right circumstances. 

[Ref. 5] 

Personnel decision-making is a never ending process, 
encompassing not only individual diagnosis and job analysis, 
but also job design, career guidance, and personnel develop- 
ment and training. People differ greatly from one another, 
but this fact does not carry implications about the static 
or dynamic nature of .human abilities, needs, motives, and 
behavioral tendencies. In fact, the pervasiveness of both 
the inter- and intra-individual differences, and the tempo- 
ral changes in human qualities are precisely why psycholo- 
gists must take such special care in individual diagnosis as 
a basis for making sound personnel decisions. Scientific 
evidence about the individuality of people should supplant 
the hunches, arbitrary judgments, invalid rules of thumb, 
and methods of trial and error that unfortunately have char- 
acterized so many programs of personnel selection and job 
placement in the past. Learning about people systematically 
and scientifically is the best avenue toward wise and effec- 
tive utilization of our human resources. 
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Marvin D. Dunnette [Ref. 5] calls 

...personnel selection a gigantic casting 
pro cess--a process in which auditions occur and in 
which human behavicr is assessed. wisely or 
unwisely, validly or invalidlv. obviously, the 
fairness of such auditions and' their relevance to 
per romance is the central concern of the Derson- 
r.el decision maker. 

Ideally, personnel decision making extends much further 
to include the possibilities for job redesign, counseling 
and guidance; the removal of organizational constraints; and 
the design of specialized training or development programs. 
Thus mapping the individuality cf persons is necessary not 
only for personnel selection and placement, but for all 
other personnel programs as well. 

The Indonesian Navy takes in hundreds of men each month; 
they must be placed into an extremely broad range of duty 
assignments, training programs, and schools. Each man 
inducted must be utilized somewhere in the system. The prob- 
lem involves very detailed classification, and it is desira- 
ble for both the Navy and the men involved to ensure that 
assignment procedures successfully achieve a close match 
between human skills and job requirements. 

B. ASPECTS OF NAVAL PERSONNEL MANAGEMENT 

The Management of the Navy‘s personnel system provides a 
means to activate the system, use it as a communication 
fool, conform to the social changes, and coordinate with the 
other sub-systems in the Navy. This management includes two 
major aspects, each with several subfunctions: (1) a man- 

power building aspect which includes functions involves 
planning and investigation, and (2) a personnel administra- 
tion aspect which includes functions involving procurement, 
education and training, assignment, treatment, and 
separation . 
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1. The Man powe r Building A spa ct 

In personnel planning it must be determined what posi- 
tions must be filled (what professions are needed) and what 
skills are needed to accomplish the required goals of the 
Navy's organization. Planning must take place on how to fill 
these positions either with personnel the Navy currently has 
or by procuring new personnel. To accomplish this it is 
necessary to carefully investigate or examine all of the 
relevant factors, internal and external, which influence the 
validity and success of this planning. Internal factors 
include all the problems which relate to the personnel sys- 
tem itself, while external factors are those which come from 
outside the Navy that directly and/or indirectly influence 
its personnel planning. 

2 . Pers cnnel Adai nist ra ti on 

This second aspect of personnel planning includes a 
number of sub-f unctions. They are: 

t 

a. Personnel Procurement 

Personnel procurement is the process of gaining 
man cower for filling vacant positions which cannot be filled 
from within the organization itself. Efficient procurement 
perscnnel must have information concerning the candidate's 
education, qualifications, experience, skills, ere. After 
candidates have been selected, their data can be keen and 
maintained so that it can be used at any time for transfer, 
new assignment, promotions, etc. 
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fc. Personnel Education and Training 

Information regarding the education and training of 
personnel is used mainly for personnel development and pro- 
motion. This information is used to match or minimize the 
difference between skills required to fill a position and 
the skills pcssesed by those who will occupy the position. A 
person's educational background can be used to gain special 
knowledge needed placing a person in a particular job and to 
prepare that person for a new assignment. Further, this 
information can be used to plan and monitor the careers of 
leaders, or those personnel with special abilities who will 
be future leaders, to extend their abilities and skills in 
preparation for future positions. 

The results of personnel development can be mea- 
sured by observing the performance of individuals in gaining 
necessary skills and abilities. This information can be 
recorded in the personnel data and used as a basis for 
further career development. 



c. Personnel Assignment 

Personnel assignment deals primarily with selecting 
the right people for the right positions. Two aspects must 
be ccnsidered: 

(1) Every vacant position must be filled by a per- 
son with the ability to carry out the job in the best man- 
ner, and 

(2) The abilities and skills of each person must be 
fitted to the job so that he feels satisfied with the job 
ar ea . 

In order to accomplish the above, it is necessary 
to have a profile of the ska 11/ability of each position, a 
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and a 



profile cf the skill/ability of each person concerned, 
periodic evaluation of each person. 



d. Personnel Treatment 

Personnel treatment deals with the physical aspects 
of the person and the job. These include such things as men- 
tal and physical health, physical work and recreation, 
rewards, and personnel services. The latter benefits include 
transportation, salary, retirement plans and insurance, 
vacations and annual and sick leave, and cooperation between 
the worker and the employer. 

e. Personnel Separation 

Personnel separation occurs when the person volun- 
tarily asks to be released from the military or goes through 
the process of retirement. Information about the people who 
are terminating must be completed in order for the personnel 
management system to give leads (directions) to other oppor- 
tunities and fields. This can be beneficial to both the 
individual and to the system. If the person voluntarily 
leaves, the system should be able to gain valuable insights 
into ways of improving the Navy so as to reduce the number 
of voluntary separations. 

3 • Co nclusions 

It can be clearly seen that the personnel management 
system must have a great deal of relevant information in 
order to proceed efficiently and effectively through all of 
the aspects involved. This supporting information must be 
complete and it must be up-to-date. This can be accom- 
plished only if the relevant data is also complete and 
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up-to-date. Moreover, in order to meet the needs of all of 
the functions, management must also keep historical data 
such as rank, profession, education, etc. 

It can also be seen that one function may need the 
same information as another function. For example, the edu- 
cation and training function needs information about the 
educational history of a person so that it can be used to 
fit/match an assignment or profession to that person. This 
same information would again be used at the time of separa- 
tion for helping the person into a new position. 

If each function were separately filed ar.d managed, 
the information for each individual, there would be great 
duplication. In addition, if the data in one file changed, 
the data in the ether files would also need to change; this 
would necessitate a great deal of time and energy in updat- 
ing several files containing the same information. In order 
to prevent this duplication of files and to save time and 
energy, a Personnel Data 3ase is needed. This would be a 
collection cf data, either historical or otherwise, which 
could be used in all functions of personnel management. 
Updating , inserting, and deleting of information could be 
performed only once. This would become the Personnel Data 
Base . 



TTPICAL 


USER 


REQUEST 


AND APPLICATIONS 




3efore 


di scu 


ssing 


a typical Navy 


user information 


quest. 


it is 


necessary to define what 


the user is in this 



system. According to C.J. Date [Ref. 3] there are three 
broad classes of users: 

1. The application programmer, who is responsible for 
writing application programs which use the Data Base. 
These application programs operate on the data in all 
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the usual ways: retrieving information, creating new 

information, and deleting or changing existing infor- 
mation. The programs themselves may be conventional 
batch applications, or they may be on-line programs 
that are designed to support an end-user interacting 
with the system from an on-line terminal. 

2. The end-user, who accesses the Data Base from a ter- 
minal. An end-user may employ a query language pro- 
vided as an integral part of the system, or he or she 
may invoke a user- written application program that 
accepts commands from the terminal and in turn issues 
requests to the DBMS on the end-user's behalf. Either 
way the user may, in general, perform all the func- 
tions of retrieval, creation, deletion and modifica- 
tion, although it is probably true to say that 
retrieval is the most common function for this class 
of user. 

3. The Data Base Administrator (DBA), who is the person 
(or group of persons) responsible for overall control 
of the Data Base system. This control includes: 

a) Deciding the information content of the Data Base. 

b) Deciding the storage structure and access 
strategy. 

c) Making liaison with users. 

d) Defining authorization checks and validation 
proced ur es . 

e) Defining a strategy for backup and recovery. 

f) Monitoring performance and responding to changes 
in requirements. 
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In thrs Thesis "the author defines the user according to 
the three classes mention above and according to who uses 
this Data Base. 

According to the SIP-TNI-AL (Navy MIS) [Ref. 10], sys- 
tem's users include the following: 

1. Headquarters level: 

a) Manager level, 

b) Staff level, 

c) Central executive level, 

d) Support level, 

e) Field technical executive. 

2. Station level: 

a) Manager level, 

b) Staff level, 

c) Executive level: i.e. , command executive, opera- 

tional group, ship. Marine. 

3. Extra Structural level: This level is the non- 

struchured organization. 

3ased on the two major aspects of personnel system man- 
agement and their breakdowns into functions, some examples 
cf user requests and applications might include: 

1. List all officers with rank of Colonel who have edu- 
cation at the Staff and Command College level, and 
have held command of a frigate ship. 

2. List each Lieutenant Colonel's profession from Ensign 
through current profession, and their educations 
either military or general. 
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3. Recapitulate an officer's career from First 
Lieutenant through Colonel. 

4. List the data characteristics of a person. 

5« Present an information list for rank promotion pur- 
poses, listing the matrix value calculation. Include 
rank, profession, education, and security clearance. 

6. Process the automatic monthly payments. 

7, Show a list of family members (spouse, children, 
etc) . 

The output forms for this information are not included in 
this thesis, as they can vary. Also, the applications of 
this information may change and become more complicated 
according to the user requests. 



D. DATA ELEMENTS AND THEIR GROO? INGS 

A trend toward more integrated file structures has 
resulted in the grouping together of all data items relevant 
to the management and operations section of a user organiza- 
tion. The emerging Data Ease concept requires placing all 
relevant data in one Data Ease in a consistent and standard- 
ized manner, eliminating unnecessary duplication and file 
handling, and providing selective inquiry and extraction 
capabilities designed to meet a vide variety of information 
requests . 

In order to meet the requirements, the author had to 
extract specific data elements from the 1979 Navy census and 
from the file system with minor modifications. The file 
system as it is currently structured contains 100 (one hun- 
dred) separate data elements which can be extracted. These 
data elements are posted in Appendix A. 
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After making analysis of them, eliminating some redundant 
cr unnecessary duplications and adding some data elements 
which are needed for the Data Base model, the author has 
restructured the Data Base so that it now contains only 97 
(ninety seven) data elements which are divided into two 
basic groups: 

1. Data elements that are almost static in relation to 
others. These elements consist of data that will not 
be frequently changed. These data elements are also 
divided into two smaller groups: 

a) Data elements which will frequently be used or 

retrieved by applications programs would be 
grouped in Sain Identification. This group 
includes eight data elements: personnel serial 

number, name, corps, sex, birth's date, religion 
and tribe. 

b) Dana elements which would be seldomly retrieved by 
applications programs are grouped in Personnel 
Characteristics. This group would usually be used 
for intelligence purposes. This group is divided 
further into four subgroups: 

i) Marriage subgroup (this group may be 

repeated) which contains rwo data elements: 
marital status, and date of marriage. 

ii) Address subgroup (this group may be 

repeated) which contains three data ele- 
ments: address, housing status, and date of 

housing status. 

iii) Body characteristics subgroup (this group 

will occur only once) which contains eleven 
data elements: weight, height, blood type. 
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size 



hair, colour of skin. 


colour of eyes 


of shoes. 


size of hat. 


size of pants 


of shirt. 


and size of 


chest. 



iv) Category and status subgroap (this group 
vill occur only once) which contains seven 
data elements: original personal status, 

date of original personal status, current 
personal status, date of current personal 
status, personal category, date of personal 
category, and active duty obligation time 
(active duty service began). 

2. Data elements that are dynamic, frequently changed, 
and which most require replication for historic pur- 
poses. These data can be subdivided into several 
groups according to their corresponding historical 
data applications. These groups include: 

a) Ranh group (this group is repeated) which contains 

seven data elements: rank, rank snafus, date of 

rank, number of decision letter, date of decision 
letter, who gave the decision letter, and type of 
promotion. 

b) Profession group (this group is repeated) which 
will contains ten data elements: name of profes- 
sion, number of decision letter, date of profes- 
sion, number of professional warrant, date of war- 
rant, group (echelon) of profession, station, 
reporting date at station, status of placement, 
and date of placement. 

c) Education group (this group is repeated) which 

contains nine data elements: group code of educa- 

tion, educational institution's name, start date, 
completion date, station, town, result of educa- 
tion, class standing, and class size. 
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In addition this group contains the repeated 
subgroups; i.e. Subjects (which contains two data 
elements: subject name, and grade). 

d) Family group (this group is repeated) which con- 

tains seven data elements of each family and mem- 
bers: family name, family relation, sex, date of 

birth, place of birth, religion, and address. In 
addition there two repeating occurence subgroups 
data elements for each family and members: 

i) Activity & Profession subgroup (this group 

is repeated) which contains four data ele- 
ments: name of activity, place of activity, 

start date, and completion date. 

ii) Education subgroup (this group is repeated) 

which contains three data elements: educa- 

tional institution's name, group code of 
education, and result of education. 

e) Payroll group: this group need not be broken-down 

further since it is usually only for the monthly 
payroll application, which contains forteen data 
elements: date of beginning payroll, rank in pay- 

roll, payroll period (month) , number of children 
authorized family allowance, status of children 
authorized family allowance, main salary, wife's 
family allowance, children's family allowance, 
other family allowances, obligated reductions, 
rice reductions, other reductions, total salary, 
and unit of payroll. 

f) Security group (this group is repeated) which con- 
tains six data elements: violation/infringe type, 

what, where, when, why, and how. In addition there 
are two subgroups for each 7iolation/In fringe 
type: 
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i) Who Involved subgroup (this group is 

repeated) which contains three data ele- 
ments: name involved, personal identifica- 

tion, and profession. 

ii) Measures subgroup (this group might be 

repeated) which contains three data ele- 
ments: action type, start date, and comple- 

tion date. 

Data elements which will become the hey to each group can 
be found in the next chapter (Data Base Model Design). 
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III. DATA BAS S MODEL DESIGN 



A. GENESAL 

Considering the foregoing synopsis of user requirements 
and the DBMS 4 (Data Base Management System), a number of 
important questions are raised. Among these are: 

1. Shat are appropriate data structures with which to 
implement the physical Data Base ? 

2. What are the properties of a useful data model, and 
how should they be represented in the physical 
structures. 

In this chapter the author will examine the problem of 
what the Data Base should look like to the user; i.e., what 
would be the appropriate data model to implement the real 
world. 

A model is a basic system of constructs used in describ- 
ing reality. It reflects a person's deepest assumptions 
regarding the elementary essence of things. It may be called 
a world view. It provides the building blocks, the vocabu- 
lary that pervades all of a person's descriptions. A model 
is mere than a passive medium for recording our view of 
reality. It shapes that view, and limits our perceptions. 

The organization of the data is represented by a data 
model. A data model is an intellectual tool used to under- 
stand the logical organization of data. To understand data 
models fully, it is necessary to be aware of how people per- 
ceive data. Data can be discerned at several levels. At one 



♦DBMS is 
Data Base. 



the software which 
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handles all access 



to tne 



level, people logically organize their perceptions of the 
real world. Ac another level, they interpret {give meaning 
to) the real world. Finally, they use data models to 
describe and record the interpretation of the world as data 
in their computers or perhaps in seme other physical medium. 

A data model must be rich enough in structure to describe 
the significant aspects of the real world, yet it must be 
possible to determine fairly automatically an efficient 
implementation of the conceptual scheme by a physical 
scheme. The conceptual scheme is an abstraction of the real 
world pertinent to an enterprise. 

D. C. Tsichritzis and F. H . Lochovsky [Ref. 18] define a 
data model as 

a oattern according to which data -ire logically 
organized. It consists of named logical units of 
data and expresses the relationships among the 
data as determined by the interpretation of a 
model of the world. 

One of several data models can be used to represent the 
interpretation of a model of the world. The main difference 
between them is the manner in which they represent certain 
relationships among the data. 

Data values, by themselves, say nothing meaningful. Some 
information will be available if a relationship has been 
established between the values. 

A relationship is an association among several things, 
with that association having a particular significance. 
Relationship might be one-to-one, one-to-mar.y, or 
man y-to- many . 

There are 3 major data models that have been used in Data 
3ase systems: 

1. Bel a t ion al: this model is based on the set theoretic 

notion of a relation, that is, a set of k-tuples for 
some fixed k. 
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• Hier archica l: this data model is a tree, where nodes 

might represent data elements groups. 

3. Network: this is the directed graph model, where 

nodes represent sets of similar entities and arcs 
represent associations. 

To see the roll or place of the data model in the Data 
Ease System as viewed by users, can be seen in Diagram 1 as 
a general architecture for a Data Ease System extracted from 
C. J„ Date’s book (Ref. 3]. 



0 sers/ Applications: 



Users /Applications : 



A 1 . . 








B1 . . 
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Diagram J. A General Architecture for a Dana Base System 
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The Data Ease is the data as physically recorded (the 
storage structure) . In between the Data Base and the users 
is interposed the data model, which is the information con- 
tent cf the Data Base as it is viewed by the users; that is, 
to the users the data model is the Data Base. The data 
model definitions define the various types of data model 
records. 5 



In practice most users will be interested only in a small 
portion of the total data model. The facility is therefore 
provided of extracting a data submodel from the complete 
dara model by means of a data submodel description. A data 
submodel may be considered as the restriction of the total 
data model, to just that portion of interest to a particular 
group of users (the community user view). It consists of 
multiple occurrences of multiple types of data submodel 
record. 



Different terms are used to describe analogous concepts 
in different Data Base architectures. Table 1 lists terms 
used in these different models (the general model described 
in Diagram 1, the Data Base Task Group model (DBTG) , and the 
Information Management System model (IMS)) and their corre- 
lation. That is, the concepts of data model and data submo- 
del correspond respectively to schema and subshema 6 in DBTG, 
and Data Base Description (DBD) and the set of all Program 
Communication Block (PCB) plus the associated mapping defi- 
nition called Program Specification 3lock (PSB) 7 in IMS. 



5 A record is a named collection of zero, one, or more 
da*a elements or data aggregates. 

6 Sche«a is the complete description of all th? element 
in a Data Base. It includes the names and descriptions o 
all data elements, data aggregates, record occurrences, .an 
areas that are part of the Data Base. While Subschema is. 
consistent and ‘logical subset of the schema from which i 
was obtained [Ref. 7 and 6], 

7 Each physical Data Base is defined by a DBD, the map- 
ping of physical Data 3ase to storage is also specified (at 
least in' part) in the DBD. Bacn loqical Data Base is 
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Table 1. 


Comparison of 


terms in various 




Data Base Arc 


hite ctur es 


Architecture 


General 


DBTG 


IMS 


Data Model 


Schema 


set of all DBD (Data 
Base Description) 


Data Submodel 


Subsch ema 


set of all PCB (Program 
Communication Block) 
dIus the associated map- 
ping definition called 
PSB (Proaram Specifica- 
tion Block) 


Workspace 


OWA (User 
Work Area) 


I/O (Input/Output) area 


Langua ge 


Host Lanq- 
uage + DML 
[Data Man- 
ipulat ion 
Langua ge) 


Host Language + DL/I 
(Data Language/I) 


D3MS 


DBMS 


IMS Control Program 



B. APPLICATIONS TO DATA ELEMENTS GEODPS MAPPING ANALYSIS 

The decision no implement a Data 3ase is activated by the 
need to share data among a variety of diverse applications 
and to integrate data for supporting more sophisticated 
applications. 3oth of these requirements complicate the 
already difficult task of providing safe and efficient 
access to computerized data. D3MS's have evolved to answer 
two critical needs: support for more interrelated data and 

support fcr sharing data among many diverse applications. 
These goals are being achieved, in part, by providing DBMS 
software to physically link related data into complex 



defined. together with its ma DDing to the corresponding 
physical Data 3ase, by means of PC3 . Each user has its own 
PS3 (that is, ?S3s may not be shared, though two distinct 
?S3s may actually contain the same information). [Ref. 3] 
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structures using such mechanisms as pointer chains, indices, 
and sequential positioning. They are also being achieved by 
the development of Data Ease design methodologies and rules 
such as the practice of storing information in a 
non-redundant fashion so that changes by one application to 
the single ccpy of the data are seen by all its users. In 
other words, that it is expected that the updates of each 
user will be apparent to the other users of the data because 
a majcr goal of Data Base Manage ment is data sharing. 

Table 2 shows the mapping of applications to the data 
elements groups from the previous chapter (User Requirements 
Definitions and Analysis) as the external views® which 
serves as a basis for designing a data model. 

In the table, the following abbreviations are used: 
MAINID for Main Identification, PERSCHAR for Personal 
Characteristics, MARR for Marriage, ADDR for Address, 
50 DTCHAR for Body Charac- eristi cs, CATES for Category and 
Status, RANK for Rank, PROFF for Profession, EDUC for 
Education, SUBJ for Subjects, F AM for Family, FACT for 
Families's Activity, FSDUC for Families's Education, PAYROLL 
for Payroll, SEC for Security, WHO for Who involve, and MEAS 
for Measures. 



®The external view is information as presented on output 
reports, displays, etc., and its correspondence to data on 
input sources. It is this correspondence between the data 
and the information derived upon which the user's external 
view is based. [Ref. 14] 
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T abl e 2. Applications to Data Elements Groups Mapping 



No. Applications 



Data Elements Groups 
M AIN ID PERSCHAH 

HARR ADDR BODYCHAR CATEG 



1. Personal identifi- 
cation and the com- 
bination of all 
appl icaticns 

2. Personal Charac- 
teristic 

3. Sank promotion and 
regular reports 

4 . Profession 

5. Education 

6. Family 

7. Fayroll 

8. Security 



X X 

X X 

X 
X 
X 
X 

X X 

X XX X 



X X 

X X 



X 

X 

X 



X 

X 



No. Applications 



Data Elements Groups 
RANK PSOFF EDDC + SOBJ 



1 

2 

3 

4 

5 

6 

7 

8 



Personal identifi- 
cation and the com- 
bination of ail 
applications 

Personal Charac- 
ter! st ic 

Sank nromotion and 
regular reports 

Profession 

Educat ion 

Faai ly 

Payroll 

Security 



X 



X 

X 

X 

X 

X 



X 



X 



X 

X 

X 



X 

X 

X 



X 

X X 



30 



Iaj2.1§ 2. (continued) 



So. Applications 



Data Elements Groups 



PAH + PATBOLL SEC 

(FACT S FEDUC) (WHO S HEAS) 



1. Fersonal identifi- 
cation and the com- 
bination of all 
application s 

2. Personal Charac- 
teristic 



X 



X 



X 



3. Sank Dromotion and 
regular reports 



X 



4. Profession 



X 



5. Education 



X 



6. Family 



X 



7. Payroll 



X 



8. Security 



XXX 



Considering 
requirements, 
local 7iew* for 



the external view and special processing 
now the author can determine the required 
each application function, as depicted in 
Diagram 2. Note: circled numbers 1 through 8 represent the 
application numbers depicted in Table 2. The relation 
attribute shewn in Diagram 2 is named "need." 



■s The local view represents that portion of the Da>a 
required to supcort a particular application function 
Generate the external view or, in the case of update, 
absorb the external view. The collection of local views 
the various applications functions using the Data 3ase 
ermines the requirements of the external view. [Ref. 14] 



Bas 

to 
for 
d st- 
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0)0 




Diaaraa 2. Local view for aach application 
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C. DATA MODEL DESIGN 



New is the time to derive the required content and struc- 
ture of the internal viev^o which is the end result of the 
data model design. The primary tool in Data Base design is 
a good data model design which satisfies the organization's 
requirements and specifies the conceptual design. 

Seme characterization of a "good” conceptual design as 
extracted from Diane C. P. and J. M. Smith paper [Hef. 16] 
are as follows: 

Concept complete: derivable concepts should be included. 

This concept guarantees that no useful objects are left 
cut of the Data Base and that designers are not inappro- 
priately constrained. For many derived concepts the der- 
ivation can only be made in one direction, but when the 
derivation is reversible there may be a performance rea- 
son for choosing one object to be the base and the other 
to be derived. 

Evolvable: it should be locally modifiable and it should 
be flexible in supporting user interpretations. 

Locally modifiable in each iterations produced by the 
design process will make the process becomes easy and 
time saving. Flexibility of interpretation is another 
property that facilitates the design process in that new 
applications may be added with potentially little impact 
on the existing design. 

Independence of existing installation and DBMS 
constraints. 



l0 The internal view is the complete data structure main- 
tained by the system to generate the multiple local views. 
The internal view describes the Data Base itself. [Ref. 14] 
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Develop the design independent of current state 
limitations and convert ions first and then tailor it to 
the system. When changes occur the original design will 
be available to facilitate system update or conversion. 

From the local view as depicted in Diagram 2, the author 
can derive the relationship between the data element groups 
as tc the owner and the member 11 as depicted in Table 3. The 
relationship "is-part-of " is the attribute name of the rela- 
tionship from the member to the owner, or attribute name 
"has- 1,12 from the owner to the member. 

Regarding the data model, further Diane C. P. and J. M. 
Smirh [Ref. 16] define each of the following properties con- 
tribute to the value of a "good" data model: 

It should be expressive. 

A data model should be sensitive to important distinc- 
tions, so it will guide its users to include the concepts 
and objects necessary to a good design. 

It should not over-cons train implementors. 

The data model should not imply a particular implementa- 
tion strategies and its vocabulary should be at a high 
enough level to be free of implementation connotations. 

A data model should have a formal basis. 

This provides the physical designers and implementors 
with a sound foundation for verifying their work and eli- 
minates the ambiguity. 



n?he cwner is the same as master, superior or parent 
arouc which has zero or more member (subordinate or cepen- 
dentj group of data elements. 

t2Where "-personal characteristic," "-rank," 

"-profession," etc! are substituted for "- ". 

3U 



Table 3. Data elements groups (as owner-member) 
r elationship 



Owner 



M AINID 



PERSCHAH 



RANK 

PROF? 

2 COC 

FAN 

PAYROLL 

SEC 



Member 

MAINID PERSCHAR RANK PROFF EDUC FAS PAYROLL SEC 
abed efg hi 

X X X X X X X 



X X X X 



X 



X X 



X X 



Note: a = MARR, b = ADD E, c = 30DYCHAE, d = CAT EG, e = SU3J, 
f = FACT, g = FSDUC, h = WHO, i = SEAS. 



A data model should be widely applicable. 

Tc produce an integrated design that can be checked for 
internal consistency, we have to use one data model which 
encompass applications that are very dynamic, very scien- 
tific, and very commercial in their orientation. 
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A data model should be understandable 



A data Model should provide some kind of non-technical 
presentation, pictorial, and utilising the terminology 
and linguistic constructs of the end user. 

Finally and most fundamentally, a data model must reflect 
and support human concept formation and understanding. 

The composition rules (syntax) of the data model do not 
force its users to assemble objects in ways that differ 
from how they would naturally assemble them, because 
humans have innate mechanisms for coping with complexity. 

The utility of a data model depends not just on the prop- 
erties described above, but also on the existence of a set 
of rules or a methodology for using it. Without such gui- 
dance many designs may be produced even using a good data 
model before an acceptable one is achieved. 

The method for modelling the individual structured compo- 
nents pertinent to an enterprise and their interrelation- 
ships is based on mechanisms that human use for thinking 
about such things. It is the premise of this data model that 
we as human beings succeed in understanding complex systems 
by creating abstractions from that can be named and con- 
ceived of as a whole. Thus, an abstraction of a system is a 
collection of details that can be treated as a whole. 

Finally from all of the above analysis author can derive 
a data model as depicted in Diagram 3. 

The data elements which are in the groups can be seen in 
chapter 2 section D (Data Elements and Their Groupings). 

The key cf each group is: personal serial number for 

Main Identification group (this also as the main key for 
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Di agra m 3. Personnel Data Model 

each person), marital status for Marriage subgroup, housing 
status for Address subgroup, blood type for Body 
Characteristic subgroup, current personal status for 
Category and Status subgroup, rank for Rank group, echelon 
of profession for Profession group, group code of education 
for Education group, subject for Subjects subgroup, family 
relation for family group, name of activity for Activity 
subgroup, family group code of education for Family 
Education subgroup, unit of payroll for the Payroll group, 
violation/infringe type for Security group, name involved 
for Kho involved subgroup, and action type for Measures 
subgroup . 

Fcr the complete description see the Data Base dictionary 
in Appendix B. 
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D. SPECIAL DISCUSSIONS 



1 « Pers onal Seria 1 Numb er 

The personal serial number is the main key in the 
Personnel Data 3ase. Many significant differences exist 
between military and civilian serial numbers. Even within 
the military there are a large number of major differences. 
In order to make accessing the Data 3ase easier, the per- 
sonal serial number must be transformed into a common form 
before they are actually stored in the Data Base. Thus, a 
routine must be designed to transform the various forms of 
personal serial numbers into a common form before storing 
them in the Data Base and then transform them back to their 
original form upon retrieval. 

Selow are the recommended transformations for personal 
serial numbers: 



a, military: 

1 ) . Officer : 



a) 



Regular: OONNNNNNN 

Example: 3999/P == = = > 000008999 



b) • 

c) . 



Titular: 10NNNNNNN 

Example: 7183/PT = ===> 100007183 

Military obligated: 20YYNNNNN 



Example: 7919786/W =====> 207919786 



2). Warrant Officer and below: 



a) . Regular: 30NNNNNNN 

Example: 93246 == = => 300093246 

b) . Military obliged: 40YYNNNNN 

Example: 8025134 = ===> 408025134 
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b. Civilian: 5 NNNNNN NN 
Example: 30599791 = 



> 530599791 



2 • Se curi ty Gr oup 

This group is provided as an additional one because of 
its importance to users. There is no data available for it 
at the present in Dispullahtal, but it is maintained in the 
Intelligence-Security Office. 

This group can only be accessed by authorized 
Intelligence-Securit y Personnel, and thus it must be given 
special treatment. Only those who are priviledged to use it 
can access these groups/segments. Thus, data security 13 is 
required for this group. The issue of security enforcement 
involves two things: (1) authorization procedures which not 

only help in user identification but allow users to deter- 
mine their own passwords, and (2) control by the system of 
user actions after authorization is given. Security con- 
trols range from simple sign-on procedures that access to 
the whole system, through passwords that control access to 
different levels of the Data 3ase, to elaborate access 
matrices and programmed procedures. Furthermore, coopera- 
tion between the Intelligence-Security officer and the DBA 
is a must in controlling and maintaining the security data 
element group. 

3. Data Di et ionary/Directo rie s (DD^D) 

Individual DBMS' have their own methods to predefine 
data descriptions. Each has a repository for the Data Base 



1 3 Da ta security is protection of the data against unau- 
thorized disclosure, alrer ation, or destruct ion . '[ Ref . 17] 



39 



description, a language facility to process that 

description, and a mechanism tc input that description to 
the EB3S. 

The general objectives of a DD/D [Ref. 19] are to: 

Prevent unplanned redundancy and inconsistency in appli- 
cation systems development in the areas of source-data 
collection, processing, secondary storage, and informa- 
tion to users. 

Reduce application systems development and implementation 
lead times and costs. 

Reduce applications modification lead times and costs. 

Aliev for establishment and enforcement of standards 
relating tc data usage and responsibility (format, mean- 
ing, validity, timeliness, and so forth). 

In most DBMS's the included data dictionary is primar- 
ily oriented toward the internal representation or the 
machine use cf the data definition. It defines the internal 
form, physical location, and access to the stored data. Clay 
R. Sprowls [Ref. 17] says that the data dictionary is pri- 
marily 

a directory that defines the internally necessary 
attributes of the data, their physical character- 
istics, and stored locations. 

The Data Base description does contain some dictionary 
information oriented toward the user. But it does not pro- 
vide all of the information that a good dictionary should 
provide for the variety of users who need access to data 
descriptions. Clay R. Sprowls [Ref. 17] lists some sug- 
gested contents of data dictionary as follows 

Osage: status (tentative or approved) , effective data, 

programs (used by), and users (both formal and informal). 
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Relationships: field (group, record, file, set, network), 
linkage (pointers to and fro a) , parent of, child of, 
sorted order by key, and relative position in data 
description. 

Administrative control: ownership (department, department 
position), definition (proposed by, analyst name), 
authority to access data (to define, to add or delete, to 
change) , security (special provisions) , source (input, 
document description, generated, and algorithm to 
ccmpu te . 

Identification: label, programming language name, syno- 

nyms (if same data field is used more than once), textual 
descriptions (including perhaps keyword descriptions), 
version number (for validation changes), lost change dare 
(for keeping dara definitions current) . 

Technical specifications: data type (quantitative or qua- 
litarive), use (external and internal), form of each use 
(length, representation or picture, precision, mode, 
j usti f icar ion , report form edited) , unir of measure, time 
dependency (for update) , accessing (record key or index), 
dara validarion, edit masks (valid codes), value range, 
and test data (for program listing). 

An exact list of dictionary conrents for an organiza- 
tion and its DBMS depends upon the breadth and emphasis it 
places on the use of the dictionary. The data dictionary 
for the Personnel Data 3ase and its description are depicted 
in Appendix B. 

4 • Journalizing 

A Data Base Management System must provide a means to 
resrcre the Data Base to a consistent state that reflects 
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the situation after some number of transactions were com- 
pleted. The journal is a basic accounting record in which 
all transactions of a certain type are recorded. A system 
journal records every transaction that occurs within the 
system. Jeffrey D. Ullman [Ref. 20] lists the most general 
case of journal entries which consists of (1) a unique iden- 
tifier for any transaction causing a change, (2) the old 
value of the item, and (3) the new value of the item. 

In this Data Base the author suggests that journal 
entries consist of: 

Identification of the users accessing the Data Base. 

Type of operation accessing the Data Base (update, 
insert, delete, list, etc.). 

Pointer to the record being accessed. 

Personal serial number of the record being accessed. 

The old value of the item. 

The new value of the item. 

Time and date of the beginning and of the end of transac- 
tions and accesses. 

Summaries which contain the numoer of personnel in the 
Navy either military or civilian, number of personnel in 
each rank. 

5 . Administ r ation 

The Data 3ase administration is the agency which exer- 
cises centralized control over the Data 5ase System. It 
includes several specialties, including information system 
analysis, data structure and data storage organization 
design, security, recovery, auditing, and accounting. Each 
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of these specialties may be assigned to one individual for 
an uncomplicated Data Base used under undemanding 
cond itio ns . 

The individual in charge of the Data Base administra- 
tion is the Data 3ase Administrator (DBA). The DBA uses the 
computer to build and operate his tools. Such tools may 
include system flow analysis tools, data relationship analy- 
sis tools, performance simulators, data storage organization 
and reorganization tools, and other utilities. Eeside the 
DBA the personnel with the specialties mentioned above must 
be organized to manage and improve the Data Base. 
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IV. CONCLUSIONS AND RECO MEN DA TIONS 

This thesis project explored the step-by-step logical 
design of the Personnel Data 3ase model which covers: 

1. Gathering, recording, and analyzing the user require- 
ments, including the analysis of the applications 
function and determining data element groupings. This 
Data Base consists cf 97 (ninety seven) data elements 
which have been divided into 17 (seventeen) data ele- 
ment groups. 

2. Deriving and designing a logical data model, includ- 
ing the analysis of data element groups relation- 
ships, applications to data element groups relation- 
ships, and determining the Personnel Data Base model. 
The structure of the data model designed is hierarch- 
ical. The Data Base dictionary was also designed as 
a directory for the Data 3ase and is included in 
Appendix 9. 

The Data Base design effort is not completed, and can not 
be, until the logical design is finished. After this has 
been done the logical design must be transformed to a physi- 
cal design. The author’s recommendations are: 

1. To continue and to complete the design. This involves 
applying this data model to a physical machine. 

2. To form and organize a Data Base administration, 
identifying the personnel needed to manage and 
improve the Data Base. 
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APPENDIX A 



LIST OF DATA ELEMENTS FROM F ILE SYSTEM 



1. Personal Serial Number 

2. Check Digit of the Personal Serial Number 

3. Duplication Cede of the Personal Serial Number 

4. Batch Number 

5- Name's Spelling Cede (Old or New) 

6 - Name 

7. Original based name from 

8. Corps 

9. Named based originally from 

10. Current Personal Status 

1 1. Date of Current Personal Status 

12. Personal Category 

13. Date of Personal Category 

14. Date of 3irth 

15. Current station 

16. Current Rank 

17. Active Duty Obligation Time (Active Duty Service 
Began) 

18. Sex 

19. Marital Status 

20. Number of Wives 

21. Number of Children 

22. Number of Children Authorized Family Allowance 

23. Status of Children Authorized Family Allowance 

24. Status of House 

25. 3 Iced Type 

26. Weight 
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27. Height 

28. Color of Skin 

29. Hair 

30. Color of Eyes 

31. Size of Shoes 

32. Size of Hat 

33. Size of Pants 

34. Size of Shirt 

35. Size of Chest 

36. Unit of Administration 

37. Unit of Payroll 

38. Unit of Individual's Field Provisions (Equipment) 

39. Unit of Side Dishes Honey 

40. Religion 

41. Tribe 

42. Place of Birth 

43. Sank 

44. Status of Sank 

45. Date of Rank 

46. Decision Letter of Rank 

47. Date of Decision Letter of Rank 
46. Who Gave the Decision Letter 

49. Type of Promotion 

50. Date of Profession 

51. Status of Placement 

52. Date of Placement 

53. Station 

54. Reporting Date 

55. Profession's Name 

56. Rank in Profession 

57. Decision Letter of Profession 

58. Date of Profession's Decision Letter 

59. Warrant of Profession 

60. Date of Warrant of Profession 
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6 1. Echelon (Group) of Profession 

62. Group Code of Education 

63. Start Date of Education 

64. Completion Date of Education 

65. Place of Education (Station, Town) 

66. Educational Institute's Name 

67. Result of the Education 

68. Class Standing 

69. Class Size 

70. Relative's Identity 

71. Relative's Name 

72. Relative's Relation 

73. Relative's Sirth Date 

74. Relative's Sex 

75. Relative's 3irth Place 

76. Relative's Religion 

77. Code of the Relative's Description 

78. Relative's Description 

79. Date of Payroll 

80. Rank in Payroll 

81- Status of Payroll Period 

82. Payroll Period 

83. Marital Status in Payroll 

84. Main Salary 

85. Wife's Family Allowance 

86. Other Family Allowance 

87. children Family Allowance 
38. Extra Earnings 

89. Main Reduction of Salary 

90. Rice Reductions 

91. Advance Payment Reductions 

92. Housing Reductions 

93. Loss-damage Reductions 

94. Other Reductions 
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the Reduction of the Advance 



95. Seduction's Code 

96. Completion Date for 
Payment 

97. Completion Date for the Seduction of Loss-damage 

98. Completion Date for Other's Reduction 

99. Salary Round-off 
ICO. Unit of Payroll 
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APPENDIX B 



DATA B ASE DI CTIONARY 

This data dictionary contains descriptions of the 
Personnel Data Base segments (data elements groups) and 
their data elements. There are six columns in the table: 

1. Element Number (ELS #). The data element/segmer.t 
number contains four digits. The first two digits is 
the segment number, beginning from the root and 
increasing by one (leading zeroes suppressed), and 
another two digits for the data element number in the 
segment beginning from one and increasing by one. 

For example: 1005 indicates the tenth segment and 

data element number five in the segment. 

2. Data Element (DATA-ELE8E NT) • This column contains 
data element/segment name as it is known to the 
users. 

3. Data Name (DATA-NAME). This column contains the uni- 
que name for data element/segment which is to be used 
by programmer/user when retrieving data from the Data 
3 as e. 

4. Type (TYPE). This column contains the data element’s 
type where N means Numeric and AN means Alpha 
Numeric. 

5» Number of Character (# OF CHAR). This column con- 
tains number of characters in the record field of the 
data element/segment. 
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6. Description (DESCRIPTION) . This column contains the 
description of the data element/segment. Described 
are the data element/segment relationships (depen- 
dent, root, etc.), key record/segment, administrative 
control, usage, and identifications. This description 
helps the programmer/user to find the path to desired 
data element/ segment in the Data Base. 

The abbreviations used in the data dictionary 
table are: D3 for Data Base, segm for segment, lev 

for level, tbl for table and refer to the Personal 
Tables (numbered in parenthesis) in APPENDIX C. 
YYMMDD for Year (two digits) Month (two digits) and 
Date (two digits) , cccurr for occurrence, depenat for 
dependent. Kg for Kilogram, and Cm for Centimeter. 



ELM 

I 


DATA- 

ELEMENT 


DATA- 

NAME 


TY- 

PE 


# OF 
CHAR 


DESCRIPTION 


100 


Main identification 


MAI NID 




76 


Root segm DB 
lev 1, segm 1, 












one occurr 


101 


Personal Serial 


SERNUM 


N 


9 


Record key 




Hum ber 








(Main key) 


102 


Nam e 


NAME 


AN 


26 


Name, title 


103 


Ccr ps 


CORPS 


N 


3 


See corps tbl 
(19) 


104 


Sex 


SEX 


N 


1 


See sex tbl (3) 


105 


Birth date 


DM3IRTH 


N 


6 


YYMMDD 


106 


Birth place 


PM3IRT H 


AN 


15 


Town (city) 


10 7 


Religion 


E2LIGI ON 


N 


1 


See religion 
tbl (12) 


108 


Tri be 


TFI3E 


AN 


15 


- 
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200 


Personal 


CHARACT 






Dependt segm of 




characteristics 








root, lev 1, 
segm 2, one 
occurr 


300 


Marriage 


MAR a 




7 


Dependt segm of 
CHARACT, lev 3, 
segm 3, 












repeated 


30 1 


Marital status 


MAR ST 


N 


1 


See marital 
status tbl (4) , 
segm key 


302 


Date cf status 


MARDT 


N 


5 


YYMMDD 


400 


Address 


ADDR 




33 


Dependt segm of 
CHARACT, lev 3, 
segm 4, 
repeated 


40 1 


Address 


ADDRSS S 


AH 


26 


- 


402 


Housing status 


HOOSS 


N 


1 


See housing 
status tbl (6) , 
segm key 


403 


Date cf status 


HOOSEDT 


N 


6 


YYMMDD 



500 3cd7 characteristic EODYCH AR 18 Dependt segm of 

CHARACT, lev 3 , 
segm 5, one 
occurr 



501 Weight 

502 Height 



WEIGHT N 3 In Kg 

HEIGHT N 3 In Cm 
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503 


Blood 


♦ 


ype 


BLOOD 


N 


1 


See 


blood 


type 
















tbl 


C) , 


segm 
















key 






504 


Color 


c 


f skin 


SKIN 


N 


1 


See 


color 


of 
















skin 


tbl 


(8) 


505 


Hair 






HAIR 


N 


1 


See 


hair 


tbl 
















(9) 






506 


Color 


0 


f eyes 


EYES 


N 


1 


See 


color 


of 
















eyes 


tbl 


(10) 


507 


Size 


of 


shoes 


SHOES 


N 


2 


- 






508 


Size 


of 


hat 


HAT 


N 


2 


- 






509 


Size 


of 


pants 


PANTS 


N 


1 


See 


pant 


shirt 
















tbl 


(11) 




5 10 


Siz e 


of 


shirt 


SHIRT 


N 


1 


See 


pant 


shirt 
















tbl 


(11) 




51 1 


Siz e 


cf 


chest 


CHEST 


N 


2 


- 







600 


Category 


and status 


CAT EG 




29 


Dependt segm of 
CHARACT, lev 3 , 
segm 6, one 














occurr 


601 


Ori ginal 


personal 


ORPERS T 


N 


2 


See personal 




sta tus 










status tbl (1) 


602 


Date cf 


origina 1 


CRPERDT 


N 


5 


YYtlMDD 




per scr.al 


stat us 










603 


Current 


personal 


CHPERST 


N 


2 


See personal 




sta tus 










status tbl ( 1 ) , 
segm key 


604 


Date of 


current 


CRPERDT 


N 


5 


YYMMDD 




personal 


stat us 










605 


Personal 


category 


CATEGO RY 


N 


1 


See personal 
category tbl 



( 2 ) 
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606 


Cate cf personal 
cat eg or y 


DTGORY 


N 


6 


YYMMDD 


607 


Active duty obliga- 
ted time (Active 
service duty began) 


DTACT 


N 


6 


YYMMDD 


700 


Ran k 


RANK 




39 


Dependt segra of 
root, lev 2,segm 
3, repeated 


70 1 


Ran k/ Group 


RAN KG 


N 


2 


See rank tbl 












(18), segm key 


702 


Status of rank 


STRANK 


N 


1 


See status of 












rank tbl (13) 


703 


Date of rank 


DTRANK 


N 


6 


YYMMDD 


70U 


Number of decision 


N3DSCLET 


AN 


8 


Format: NNNNMMYY 




letter 








NNNN : number 












MM : month 












YY : year 


705 


Date of decision 


DTDECLST 


N 


5 


YYMMDD 




let ter 










706 


Who gave the decisi- 


GVDECLET 


AN 


15 


Official 




on letter 








functionary 


707 


Type cf promotion 


TP PROM 


N 


1 


See type of 
promotion tbl 
(14) 


800 


Pro f ess icn 


PROFSS S 




71 


Dependt segm of 
root, lev 2, 
segm 4, 
repeated 


801 


Name cf profession 


NMPROF 


AN 


15 


- 
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832 


Number of decision 


NBDEC? 


AN 


8 


Format: NNNNMMYY 




letter 








NNNN: Number 












MM: Month 












YY: Year 


803 


Date of decision 


DTPROF 


N 


5 


NNNNNN-YYMMDD 




let ter 










804 


Number cf pro fessi- 


NBWARP 


AN 


8 


Format: NNNNMMYY 




onal warrant 








NNNN: Number 












MM: Month 












YY: Year 


805 


Date cf warrant 


DT’WAR? 


N 


5 


NNNNNN-YYMMDD 


806 


Echelon of 


ECHELON 


N 


2 


See echelon 




pro f ess icn 








tbl (21) 


907 


Sta tioc 


STATIC N 


N 


3 


See station tbl 












(22) 


808 


Heporting date 


DTSTAT 


N 


6 


YYMMDD 


309 


Status of placement 


STPLAC E 


N 


1 


See status of 
placement tbl 
(15) 


9 10 


Date of placement 


DTPLAC E 


N 


6 


YYMMDD 


900 


Education 


ED0C 




73 


Dependt segm of 
root, lev 2, 
segm 9, 
repeated 


90 1 


Group code of 


EDUCCD 


N 


3 


See group code 




education 








of education 
tbl (20) , segm 
key 


902 


Educational Insti- 


EDUCNM 


AN 


15 


- 




tute's Name 










903 


Start date 


EDO CSD 


N 


6 


YYMMDD 


904 


Completion date 


EDO CCM 


N 


6 


YYMMDD 
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905 


Station 


EDS TAT 


N 


3 


See station 
tbl (22) 


906 


Town (city) 


EDTOSN 


AN 


15 


- 


907 


Result of education 


RESULT 


N 


1 


See result of 
education tbl 
(16) 


908 


Class standing 


CST AND 


N 


3 


- 


909 


Class size 


CSIZE 


N 


3 


- 



1000 


S ub j e ct s 


SUBJ 




18 


Dependt segm of 
EDUC , lev 3, 
segm 10, 
repeated 


100 1 


Subject name 


SUB JSC T 


AN 


15 


Segm key 


1002 


Gra de 


GRADE 


AN 


3 


Can be numeric 












or alphabet 


1100 


Family 


FAM 




76 


Dependt segm of 
root, lev 2, 
segm 6, 
re peated 


1101 


Family name 


FNAKE 


AN 


26 


Name, title 


1102 


Family relation 


FREL 


N 


1 


See family 
relation tbl 
( 17) , segm key 


1103 


Sex 


FSSX 


N 


1 


See sex tbl 












(3) 


110U 


Birth date 


FDBIRT H 


N 


6 


YYMMDD 


1105 


Birth place 


FPBIRTH 


AN 


15 


Town (city) 


1106 


Religion 


FRSLIGI 


N 


1 


See religion 
tbl (12) 


1107 


Address 


FADDR 


A N 


26 
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1200 


Acr i vit y 


FACT 




48 


Dependt segm 
FAM, lev 3, 
segm 12, 
repeated 


1201 


Name of activity 


FNACT 


AN 


26 


Segm key 


1202 


Place of activitv 

-4 


FPACT 


AN 


15 


Town (city) 


1203 


Start date 


FSACT 


N 


6 


YYMMDD 


1204 


Completion date 


FCACT 


N 


6 


YYMMDD 



1300 Family education F2DUC 



1301 Educational Insti- PEDNACT AM 

tut a ' s Name 

1302 Group code of FCDACT N 

education 

1303 Result of education FEDRES N 



16 Dependt segm of 
FAM, lev 3, 
segm 13, 
repeated 

15 

3 See group code 
of education 
tbl (20) , seam 
key 

1 See result of 
education tbl 
(16) 



1400 


Pay roll 




PAYROLL 


59 


Dependt segm of 
root, lev 2, 
segm 14, one 
occurr 


1401 


Date of 
pay roll 


beginning 


D3PAY N 


6 


YYMMDD 


1402 


Ran k in 


pa yroll 


RKPAY N 


2 


See rank tbl 
(18) 


1403 


Payroll 


pe riod 


FSRPAY N 


3 


In month 
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1404 


Number of children 
authorized family 
allowance 


CHFAM 


N 


1 






1405 


Status of children 
authorized family 
allowance 


STCHFA M 


N 


1 


See children 
allowance sta- 
tus tbl (5) 


1406 


Main salary 


MAINS A L 


N 


6 


In 


Rupiah 


1407 


Wife* s Family 
Allowance 


WFALL 


N 


5 


In 


Rupiah 


1408 


Children Family 
Allowance 


CHALL 


N 


5 


In 


Rupiah 


1409 


Other family allo- 
All owances 


OTALL 


N 


5 


In 


Rupiah 


1410 


Obligated reductions 


OBRED 


N 


5 


In 


Rupiah 


141 1 


Rice reductions 


RCRED 


N 


5 


In 


Rupia h 


1412 


Other reductions 


CTRED 


N 


5 


In 


Rupiah 


14 13 


Total salary 


TOTSAL 


N 


6 


In 


Rupiah 


14 14 


Unit of payroll 


UNPAY 


N 


4 


See station tbl 
(22) , segm key 


1500 


Sec urit y 


SEC 




35 


Dependt segm of 



root, lev 2, 
segm 15, 
repeated 



150 1 


Violation / Infringe 
type 


VTYPE 


N 


1 


See violation / 
infringe type 
tbl (23) , segm 
key 


1502 


What 


WHAT 


N 


3 


See what tbl 
(24) 


1503 


Where 


WHERE 


AN 


15 


Town (city) 


1504 


When 


WHEN 


N 


6 


YYMMDD 
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1505 Why WHY N 5 This reason 

description is 
stored in other 
file with key 
number here 
(N 5) 

1506 How HOW N 5 Same as 1505 



1600 


Who involved 


WHOIN7 




50 


Dependt segm of 
S EC , lev 3, 
segm 16, 
repeated 


1601 


Name involved 


INVNAH E 


AN 


26 


Segm key 


1602 


Personal 


PE3SID 


AN 


9 


Personal Serial 




identification 








number or other 












valid 












identification 


1603 


Pro f e ss ion 


PRO FIN V 


AN 


15 




1700 


Nea sures 


MEAS 




27 


Dependt segm of 
SEC, lev 3, 
segm 17, 
repeated 


170 1 


Type of action 


NMEAS 


AN 


15 


Segm key 


1702 


Start date 


SHEAS 


N 


6 


YYMMDD 


1703 


Completion date 


CHE AS 


N 


5 


TYMKDD 


— — 





— 





— 
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APPENDIX C 



DATA BASE PERSONNEL TABLES 



Each of these tables contains two elements: code 

description. Example: "1 Male" indicates code number 

Hale. 



1. PERSONAL STATUS ; 



A. Military: 

01 Volunteer 03 Titular 

02 Obliged 

B. . Civilian: 



11 Dailv_labourer 

12 Monthly_labourer 

13 Konthly_labourer organic 

14 Temporary Gover nment_of f icial 

15 ?re_Go vernment_of f icial 

16 Civilian_Government_off icial 

17 Civilian_Military_Titul ar Governaent_official 
2. PERSONAL CATEGORT: 



0 Net Clear 

1 Active organic 

2 In charge 

3 In assistance 

4 in direction 

3. SEX: 

1 Hal e 



5 Waiting for placement 

6 Waiting for direction 

7 p re r et ir ed 

8 Honey waiting (UT) 

9 R et ired 

2 Female 



and 

is 
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4. MARITAL STATUS 



1 Married 



2 ot married 



5. CHILD RES ALLOWASCE STATUS: 



1 Claimed by him/herself 

6. HCUSIHG STATUS: 

1 Government-quarters 

2 Mess 

3 Shi p 

7 With relations 

7. BLOOD TYPE: 



2 C laimed by spouse 

4 Private/owned 

5 Rented 

6 Contract/Leased 



1 A 

2 B 

8- COLOUR OF SKIH: 

1 White 

2 Yellow 

3 Black 

9. HAIR: 

1 Straight-lank 

2 Curly 

10. COLOUR OF EYES: 

1 Black 

2 Blue 

11. SIZE OF PAHTS/SHIRTS: 

1 Small 

2 Medium 

12. FELIGION: 



3 AB 

4 0 

4 Yellow-brown 

5 3rown 



3 Straight-stiff 

4 W eavy 

3 B rown 

4 Green 

3 Large 



1 Moslem 



4 H inau 
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2 Catholic 

3 Protestant 

. STATUS OF SANK: 

1 Effective 

2 Temporary 

3 In education 

14. TYPE OF PROMOTION: 

1 Regular 

2 Extraordinary 

15. STATUS OF PLACEMENT: 

0 Organic 

1 Labour (non organic) 

2 In charge (detached 
from parent command) 

16. RESULT OF EDUCATION: 

1 Graduated 

2 Not graduated 

17. FAMILY RELATION: 



0 


Spouse 






' 5 


Child 


number 


5 


1 


Child 


number 


1 


6 


Child 


number 


6 


2 


Child 


number 


2 


7 


Child 


number 


7 


3 


Child 


number 


3 


3 


Ch ild 


number 


3 


4 


Child 


number 


4 


9 


Ch ild 


number 


9 



18. HANK: 

A. Military: 

9 9 Third Sailor 
98 Second Sailor 
97 First Sailor 
96 Second Corporal 



5 Budha 

6 Kong Hu Cu 

4 Military obliged 

5 Military titular 



3 Honour (meritorious) 

4 Honour-grace (posthumous) 

3 In assistance (temporary 
additional duty) 

4 In direction (independent 
d ut v) 

3 I ncomplete 
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95 First Corporal 

88 Second Sergeant 

87 First Sergeant 

86 Head Sergeant 

85 Sergeant Major 

84 Second Assistant Lieutenant 

83 First Assistant Lieutenant 

82 Candidate Officer 

78 Second Lieutenant 

77 First Lieutenant 

76 Captain 

6 8 Ma j or 

67 Lieutenant Colonel 
66 Colonel 

58 First Admiral (Commodore) / Brigadier General 
57 Hear Admiral / Major General 
56 Vice Admiral / Lieutenant General 
55 Admiral / General 

E. Civilian: 

48 Group I/A 
47 Group l/B 
4 6 Group I/C 
45 Group I/D 
3 8 Group II /A 
3 7 Group II/3 
36 Group II/C 
35 Group II/D 
28 Group II I/A 

19. CORPS: 

A. Military: 

100 Sailor/Deck (for Officer only) 

161 Deck 

162 Torpedo 



27 


Grou p 


II 1/3 


26 


Group 


III/C 


25 


Group 


II I/D 


18 


Grou p 


IV /A 


17 


Group 


IV/3 


16 


Grou p 


IV/C 


15 


Group 


IV/D 


14 


Group 


17/S 
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1 63 Weapon 

164 Constable 

165 Signal 

1 66 Telegrams 

167 Onder-vater Weaponry 

200 Technician/Engineer (for Officer only) 

261 Machinist 

262 Construction 

263 Ship Construction 

264 Airplane Maintenance 

300 Electronics (for Officer only) 

361 Radio 

362 Radio-Radar Mechanic 

363 Electro-Machine Mechanic 

364 Electrician 

365 Sub-weapon Electrician 

366 Electro Mechanic 

367 Weapon Electro Mechanic 

368 Electronica 

400 Marine (for Officer only) 

461 Infantry 

462 Amphibious 

463 Field Artillery 

464 Air Defense Artillery 

465 Tank 

466 Pansam (Amphibious Tank) 

467 Transportation 

468 Zipur (Defense Construction) 

469 Ccmmunication-E lectro nica 

470 Nurse 

471 Field Support 

500 Administration (for Officer only) 

561 Writer/Typist 
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562 

563 

564 

565 

566 

567 

600 

661 

662 

663 

664 

665 

666 

700 

761 

762 

763 

764 

765 

766 

767 

768 

769 

800 

861 

862 

863 

8 64 

865 

866 

867 

368 

900 



Finance 

Support 

Family business 

Ccck- 1 

Cook 

Tailor 

Health (for Officer only) 
Nurse 

Radiologist 
Anaiy sist 
Dental Technician 
Chemist 

Assistant Chemist 

Specialist (for Officer only) 

Judicature 

Intelligence 

Transportation 

Carpenter 

Physical Fitness 

Musician 

Photography 

Cinematography 

Miscellaneous 

Woman (for Officer only) 

Communication 

Writer/Typist 

Finance 

Information 

Physical Fitness 

Nurse 

Nav-Inf ormation Defense 
Air Traffic Controller 

Clergy (for Officer only) 
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E. Civilian 



000 Administration 

001 General Administration 

002 Finance Administration 

003 Labour Administration 

004 Support Administration 

005 Nursing Administration 

006 Technic Administration 

007 Typist 

008 Stencil Mechanic 

009 Nursing Staff 

010 Statistic Administration 

011 Law Administration 

012 Library Administration 

013 Transportation Administration 

014 Housing Administration 

015 Post Administration 

016 Miscellaneous Administration 

017 Technic 

018 Ship Technician 

019 Engine/machine Technician 

020 Electro Technician 

021 Construction Technician 

022 Carpenter 

023 Welding Technician 

024 Telephone-telegraph Technician 

025 Radio Technician 

026 Mschanic/driver 

027 Labourer 

028 Photographer 

029 Film Operator 

030 Metal Technician 

031 Painter 

032 Weapon Technician 
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033 

034 

035 

036 

037 

038 

039 

040 

041 

042 

043 

044 

045 

046 

047 

048 

049 

050 

051 

052 

053 

054 

055 

056 

057 

058 

059 

060 

061 

062 

063 

064 

065 

066 



Firs Safety Inspector 
Constructor 
General Controller 
Shipyard Worker 
Pump Technician 
Railroad Technician 
Meteorological Technician 
Miscellan eous 

Nurse 

Dental Nurse 

General Nursing 

Midwife 

Pharmacy 

Physiotheraphy 

Radiology 

Pediatric Nurse 

General Medical 

Ophthalmologist 

Throat-nose-ear Physician 

Neurologist 

Derm at ologist 

Dietitian 

Miscellaneous 

S pecialis t 
Teacher/instr uc tor 
Messenger 
Cook 

Gardener 

Shoemaker 

Tailor 

Barber 

Janitor 

Forester 

Sketcher 
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067 Security 

068 Lifeguard 

069 Parking Master 

070 Fire Brigade 

071 Physical Fitness 

072 Artist 

073 Clergy 

074 Laundry 

075 Ocean Tide 

076 Petro-che mica 1 Technician 

077 Geography 

078 Miscellaneous 

20. GROUP CODE OF EDUCATION: 

000 General development 
C01 National defense 

002 Joint command 8 staff college 

003 Command S staff college level 

004 2nd Officer continuing education level 

005 1st Officer continuing education level 
011 NCO continuing education 

100 Formation 

101 Military Academy level 

102 Fundamental Officer Education level 

103 Candidate Officer education level 

111 Candidate NCO education level 

112 Candidate Corporal education level 

113 Candidate Enlisted Education level 

200 Labour 

201 Labour education level 

300 General education 

301 University level 

302 Academy level 

303 Senior high school level 
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304 Junior high school level 

305 Elementary school level (graduate!) 

306 Elementary school level (not graduated) 

400 Specialist Military education 

401 Specialist 

402 Officer specialist 

403 NCO specialist 

404 Enlisted specialist 

405 Civilian specialist 

500 General Course 

21. ECHELON OF PROFESSION: 



11 


Echelon 


1 -A 


23 


Echelon 


2-C 


12 


Echelon 


1-3 


24 


Echelon 


2-D 


13 


Echelon 


1-C 


25 


Echelon 


2-E 


14 


Echelon 


1-D 


25 


Echelon 


2-F 


15 


Z chelon 


1 -E 


31 


Eche Ion 


3- A 


16 


Echelon 


1-? 


32 


Echelon 


3-3 


17 


Echelon 


1 -G 


33 


,Eche Ion 


3-C 


18 


Echelon 


1-H 


34 


Echelon 


3-D 


21 


Echelon 


2-A 


35 


Echelon 


3-E 


22 


Echelon 


2-3 


40 


Functional 



22. STATION: 

Not included here for security reasons. 

23. VIOLATION / INFRINGE TYPE: 

1 Discipline 3 Negative data 

2 La w 

24. SHAT: 

This table will be completed later by Intelligence / 
Security officer, since the author does not have experience 
and data for this. 
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